Self-organization is the process where a structure or pattern appears in a system without a central authority or external element imposing it through planning. The vision of self-organization networks (SON), which is in line with the views of 3GPP (3rd Generation Partnership Project), is that future radio access network needs to be easier to plan, configure, manage, optimize, and heal compared to how it used to be. SON has been codified by the 3GPP Release 8 specifications in a series of standards. Newly added base stations should be self-configured in line with a ‘plug-and-play’ paradigm, while all operational base stations will regularly self-optimize parameters and algorithms behavior in response to observed network performance and radio conditions. Furthermore, self-healing mechanism can be triggered to temporarily compensate for a detected equipment outage, while awaiting a more permanent solution.
In 3GPP networks, Mobility Optimization including MRO (Mobility Robustness Optimization) is a reactive self-optimization function executing in eNodeB that is assumed to optimize handover (HO) parameters. For example, eNodeB needs to optimize UE measurement configuration and HO algorithm behavior to find acceptable or as low as possible HO problem rate, as well as to find a balanced ping-pong rate or HO rate. In a too late HO problem, a connection failure occurs in the source cell before the handover was initiated or during a handover. The UE attempts to re-establish the radio link connection in the target cell (if handover was initiated) or in a cell that is not the source cell (if handover was not initiated). In a too early HO problem, a connection failure occurs shortly after a successful handover from a source cell to a target cell or during a handover. The UE attempts to re-establish the radio link connection in the source cell. In a wrong cell HO problem, a connection failure occurs shortly after a successful handover from a source cell to a target cell or during a handover. The UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.
After a failure, e.g., a radio link failure (RLF) or handover failure (HOF), if UE can find another suitable cell of the same RAT, then UE will attempt radio resource control (RRC) re-establishment. According to existing Rel-9 procedures, after a successful re-establishment attempt, the network can use X2 RLF indication procedure to notify the eNB of the previous UE serving cell, and this eNB may do accounting based on this indication for mobility optimization. In Rel-10, the UE may do RLF report also after RRC establishment, e.g., after RRC re-establishment fails, possibly due to non-preparation, and when the subsequent NAS recovery succeeds.
However, there is no way for the network to correlate the subsequent RLF report with the UE context in the previous serving cell. Thus, if 3GPP goes ahead as proposed, then undoubtedly there will be double bookkeeping. First, statistics will be updated based on RRC re-establishment attempts (where RRC re-establishment fails), and statistics will again be updated based on UE RLF report. The Rel-9 and the suggested Rel-10 methods are not fully compatible with each other. Such double bookkeeping will make failure statistics unreliable, and may cause incorrect MRO actions.
Together with the contents in the RLF report, the network known information about the UE at the time of failure is essential in determining what should be the corrective actions for certain failures. For some failures, the most suitable corrective actions may be non-MRO actions, such as reconfiguration of interference coordination scheme or changes to power control etc. Because the UE context in the previous serving cell (e.g., its Cell Radio Network Temporary ID (C-RNTI)) is already known to the network, a solution is sought to always be able to correlate the network-known information with the RLF report to avoid double bookkeeping and to improve MRO decision for SON.
Another potential problem is that RLF reports may be delivered to a base-station very late, e.g. a day after the failure happened. Normally a base-station will not keep the UE context and keep the CRNTI of a UE non-reserved for a very long time, and normally a base-station has limited memory for such storage.